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A Guide to FileMaker Lookups 


By Joe Kroeger 

One of the FileMaker features that has extended 
the efficiency and usefulness of the program is the 
ability to link automatically two fields in different files 
and use the link to transfer information from one file 
into the currently-active one. This process is called a 
Lookup. Data entered into a field from an external file 
is said to have been “looked-up”. This ability repre¬ 
sents one more way to enter information automatically 
into records, thus saving keystrokes and adding to effi¬ 
ciency. T?iis article explores FileMaker lookups. 


Figure 1 

Data File Lookup File 



Lookups are used in a variety of ways. An invoice 
file can enter the name and address for a new order by 
looking up that information from a separate customer 
file. Entry of a ZIP code in an address can cause the 
City and State to be looked up and entered in the ad¬ 
dress. An order-entry file can look up the discounted 
price of a product based on the quantity ordered. 
Lookups can translate information from one ‘code’ to 
another - a mnemonic abbreviation into a product 
number, for example. Lookups solve many, many 
database problems. And lookups in FileMaker execute 
quickly and are reasonably easy to set up. 

The Lookup Process 

Figure 1 shows data being transferred from a field 
in the lookup file into a field in the data file. The first 
step in using a lookup is to specify those two linked 
fields. But Figure 1 is greatly simplified since it does 
not show how to identify the record where the destina¬ 
tion data field lives or the record where the lookup field 
lives. To do so, additional pointer fields, called key 
fields, are needed. See Figure 2. Altogether, FileMaker 
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needs to know the names and locations of 
four fields in order to implement a lookup: 
(1) a source data field in the lookup file 
that contains the information to be trans¬ 
ferred; (2) a destination data field where 


Data File Lookup File 



Destination key Destination Source Source 

field data field data field key field 


Figure 2 


Figure 3 
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the looked-up information is to be placed; 
(3) a source key field to identify an individ¬ 
ual source record in the lookup file; (4) a 
destination key field to identify an individ¬ 
ual destination record in the data file. 

Once the lookup specification is in 
place, Figure 2 works like this: when a new 
record is created and information is en¬ 
tered into the destination key field, File¬ 
Maker (1) opens the lookup file; (2) scans 
through the records of the lookup file try¬ 
ing to match the destination key and the 
source key; (3) transfers data from the 
source data field in the first record that has 
the same key into the matching destination 
data field. 

Any change in the destination lookup 
key in any record in the active data file tells 
FileMaker that a lookup should be made in 
order to synchronize the destination data 
field contents with the information point¬ 
ed to by the revised lookup key. A lookup 
can also be triggered by a Relookup com¬ 
mand (in the Edit menu). 

Notice that destination key fields need 
not contain unique information - that is, 
in a data file many of the records may con¬ 
tain the same destination key. They will 
then lookup the same information from 
the lookup file. Source key fields, on the 
other hand, often contain values that are 
unique in the file. 


Figure 4 


— 

Transfer 

r-- 1 





Data Field A 



U3T3 I - I6lu 1 



i 





Transfer 

j 






Transfer 


Data Field B 








Uata Meld 



1 Uata Meld l 



Match 


| Key Field |— — - 

**►[ Key Field 1 




_ 


Data File Lookup File 


Lookup Networks 

FileMaker provides an abundance of 
flexibility about defining lookups and 
about integrating webs of lookup links. 
Calculation fields can act as key fields and 
as source data fields (bringing up some in¬ 
teresting possibilities, by the way), al¬ 
though they cannot be destination data 
fields. Any data field in the destination file 
(except calculations and summaries) may 
have an independent lookup definition. 
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Each lookup definition can use indepen¬ 
dently any other field as a destination key 
field - even fields that are being used as 
keys for other lookup definitions, and even 
fields that are lookup destination fields 
themselves. Each lookup definition can use 
any file as a lookup file, independent of oth¬ 
er lookup definitions in the destination file. 

Figure 3 shows multiple lookup files 
feeding data into one destination file. One 
lookup file might be customer addresses. A 
second might be a product file with part 
numbers and descriptions. A third might 
be a price file with discounts. A fourth 
might be a UPS zone table. A fifth might be 
a UPS rate table. And so on. Just remember 
that each lookup file must be open and 
FileMaker Pro has a limit of 16 files open 
at one time. 

Figure 4 shows several data fields re¬ 
ceiving looked-up data from a single look¬ 
up file (and keyed in this case by a single 
destination key field). If the lookup file held 
customer addresses, the data fields might 
be FName, LName, Street, and so forth, all 
keyed, perhaps, by a NameCode field. 

In many actual cases, the lookup setup 
will be a combination of Fig- 



operating efficiency. 


Defining Lookups 

A lookup is always defined as a data- 
entry option to the definition of an indi¬ 
vidual destination data field. And each is 
defined independently, a field at a time. It 
takes three nested steps to arrive at the 
lookup definition: 

1. From the Browse or Layout mode, 
execute Define Fields... from the Select 
menu. That gets you to the field definition 
dialog shown in Figure 6. 

2. Highlight the name of the destination 
data field that you want to make into a 


Select 


✓ Browse 

XB 

Find 

XF 

Layout 

XL 

Preuiew 

XU 

Find All 

XJ 

Refind 

XR 

Omit 

XM 

Omit Multiple... 

088M 

Find Omitted 


Define Fields... 

OKD 

Sort.*. 

xs 

Uiew as List 


Figure 6 


ures 3 and 4. Indeed, there 
could be a hierarchy of look¬ 
ups as well, as illustrated in 
Figure 5. If Figure 5 looks 
complicated initially, don’t let 
it intimidate you. I’ve talked to 
several users who want to do 
everything in one file so they 
do not need to deal with 
multi-file linkages. This is of¬ 
ten a mistake. Lookup links 
are defined one leg at a time 
just like putting on pants. And 
once they are in place, you 
don't have to deal with them 
again but can instead reap the 
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Entry Options for Text Field “City” 
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Figure 7 


lookup - the field that will receive the 
looked-up data. Then click the Options 
button, taking you to the dialog shown in 
Figure 7. 

3. Assuming that the field you are de¬ 
fining to be a lookup has not been one un¬ 
til now, just check the box to the left of 


“Look up values from a file:” 
in the lower left-hand corner. 
FileMaker will then click the 
Set Lookup button for you 
and will present a standard 
open-file dialog. This is where 
you select the file that will be 
used as the lookup file for this 
lookup. When the lookup file 
name is selected, you (finally!) 
arrive at the actual lookup def¬ 
inition dialog as shown (with 
annotations) in Figure 8. (The 
process is a little different if the 
field you are working with is 
already defined to be a look¬ 
up.) If you ever want to change the name 
of the lookup file, click the Set Lookup 
File... button in this dialog. 

So far you have specified the destina¬ 
tion data field and the lookup file. In the 
dialog of Figure 8 you will tell FileMaker 
the names of the three additional fields that 
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the lookup requires: source key, destina¬ 
tion key, and source data. FileMaker pro¬ 
vides convenient lists of field names for 
each of the three, making it easy to scroll 
through and select the fields desired. (Of¬ 
ten the source and destination data field 
names will be the same, but that is not a 
necessity.) Using the popup lists, enter the 
three additional names not already filled 
in. (FileMaker has already filled in the des¬ 
tination field name in two places and the 
lookup file name. Notice that the illustra¬ 
tion on page 2-18 of the Pro manual incor¬ 
rectly shows the two different destination 
data field names.) 

The sub-box in the lower left-hand cor¬ 
ner of Figure 8 allows you to specify op¬ 
tions when the lookup process is unable to 
locate a match between the two key fields. 
The default is “don’t copy” and that is used 
quite often. We’ll discuss the others later. 

Once the definition is complete you can 
unwind yourself from the nested dialog 
boxes and test the lookup. Try entering 
information in the destination key field to 
see if the lookup responds properly. If the 
destination key is a calculated field, enter 
test data in a field that influences the 
calculation. 

Lookup Variations, Details & Tips 

A lookup key, either a destination key 
field or a source key field, can be the result 
of a calculation. This means that we have a 
lot of flexibility to create interesting and/or 
complex lookup keys. 

When looking up prices in an order- 
entry situation, one approach is to enter a 
part number which is used as a lookup key 
into a price file that has a price for each 
part number. If the proper price depends 
not only on the part number, but on the 
quantity ordered as well, it is an easy mat¬ 
ter (as one of several approaches) to calcu¬ 


late a lookup key that is a combination of 
the part number and the quantity ordered. 
Then the lookup finds not only a price for 
the part number, but a price for the quanti¬ 
ty as well. 

This means that the price lookup file 
needs to have more entries since more key 
values are possible. It also means that it is 
easy to make price adjustments without 
touching the order entry file: just change 
entries in the price lookup file. Be careful, 
however, not to execute a Relookup on old 
orders after changing the price file. 

Because lookup keys can be calculated, 
you can make a lookup conditional. Just 
make the value of the key a function of a 
field that you control. Then in the records 
where you do not want a lookup to occur, 
use the control field to force the key to a 
value that you know does not exist in the 
lookup file. This technique can be used to 
lock out further price lookups and relook¬ 
ups for completed orders, for example. 

FileMaker looks up from the first record 
in the lookup file that has a matching look¬ 
up key. The sort order in the lookup file 
does not matter. If you have multiple look¬ 
up records with the same key and you don’t 
want necessarily the first record, you need 
to revise the lookup file. You might delete 
older records that are out of date. You 
might Sort the lookup records and import 
them into a clone of the lookup file so that 
you control which records come first. You 
might refine your lookup keys to make 
them more discriminating. 

When a lookup is triggered and the 
source and destination keys match, File¬ 
Maker replaces the information originally 
in the destination data field with informa¬ 
tion from the lookup file. The original data 
is lost, even if the looked-up data is a space. 
The one exception is when the source data 
field in the lookup file is blank: blank data 
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Philosophically, 
lookups provide 
access to information 
from files that may be 
structured in ways 
quite different than 
the main file. An 
address file has one 
record = one address 
and a Zip Table has 
one record = one ZIP 
code, yet lookups 
allow them to link and 
probe and pull out 
data. 
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Figure 9 
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will not replace existing data in the destina¬ 
tion field. You should make allowance for 
this situation when designing your lookup. 
You might decide that it does not matter, 
or that it actually helps with your problem, 
or that there are no blank entries in your 
lookup file. You might decide that you 
need to clear all destination data fields that 
might need to accept a blank. You might 
decide that you will fill all empty lookup 
fields with a space. 

When defining the lookup, you must 
tell FileMaker what to do if there is no 
match between the source and destination 
keys. The options are listed in the sub-box 
in the lower left-hand corner of the lookup 
definition box. See Figure 8. In many cases 
if there is no match you will want no look¬ 
up to occur and that option is the default 
at the top of the list. Or if there is no match 
and there should be, you may want File¬ 
Maker to insert a special code or phrase, 
like the word “Error”. 

Alternatively, you can instruct File¬ 
Maker to use the next-lower or next-higher 
lookup key value. These are two very valu¬ 
able options because they allow, among 
other things, the creation of much smaller 
lookup tables. With these options, we need 
to have table entries only when there is 
some change in the data value relative to 
the key value in the lookup file. 

To make this clear, consider the exam¬ 
ple above of a price lookup that depends 


on the quantity ordered. Assume that the 
only option is an exact match, and that 
prices for part number 333 are: 


Quantity Price 

1-4 55 

5-9 49 

10-19 45 

20 and up 42 


Then the portion of the price lookup 
table for part number 333 would look 
something like Figure 9, where each row is 
a record in the price lookup file. The first 
column of numbers is the key field and is a 
concatenation of the part number and a 
two-digit quantity. This type of lookup ta¬ 
ble is sometimes known as an “indexed” 
lookup. 

Under the same conditions, except that 
we are allowed to specify “use next lower 
value”, the lookup table becomes much 
smaller: 


33301 

55 

33305 

49 

33310 

45 

33320 

42 


This works because any intermediate 
value of the lookup key - like 33308 - uses 
the price associated with the next lower key 
- 49 from 33305 - as the price to be looked 
up. It really works and it saves lots of space 
and data entry time in the lookup file. 

There are no restrictions about which 
file is used as a lookup file except that, for 


If no enact match, then 
O don't copy 
O copy nent lower ualue 
O copy nent higher ualue 
O use message 
® use file 1 


Lookup Wish 

It would be nice to have a fifth option available for no-exact-match. 
A range of sophisticated uses would open up if we could tell File¬ 
Maker to go to another lookup file when there is no key match in the 
first one. The second file could contain error messages, for example. 
Or the second file could be simply an extension of the first, allowing 
lookup tables effectively to go beyond the current 32 MByte limit. 


Page 6 • Issue 42 The FileMaker Report ©1991 Elk Horn Publishing 






convenience, it needs to be in the same 
folder as the destination data file. File¬ 
Maker aliases in System 7 do not work 
(yet) as lookups, but I expect they will one 
day and that will make things even nicer 
for lookup designers and artists. 

If you are working on a data file as a 
guest across the network, any associated 
lookup files need to be open on the net¬ 
work as well in order for remote lookups to 
take place. A local data file can work with a 
remote lookup file across an AppleTalk 
network, allowing several operators on the 
network to lookup from one master look¬ 
up file. Even with large files, lookups across 
the network are quite fast. 

An important variation of the usual 
lookup is to define the lookup file to be the 
same file as the destination file. This is 
called a “self-lookup” since the data is re¬ 
trieved from the same file as the destina¬ 
tion. Self-lookups are quite handy for solv¬ 
ing several types of database problems. You 
can collect data from an adjacent record in 
the same file, for example (see “Record-to- 
Record Information Transfers”, issue #36). 
You can look up a calculated value into an¬ 
other field in the same record, allowing the 
value to be selected and copied to the clip¬ 
board. 

Since each destination field is defined 
independently, different source fields that 
are keyed by the same destination key can 
be located in different files. This makes it 
easy to split the lookup file if it gets too big: 
just move some of the fields to another file 
that also contains the same set of source 
key information. 

Lookup Example 

As a concrete example that illustrates 
many of the points in this article, consider 
the task of looking up City and State infor¬ 
mation into an address file. The Master 


Address file contains a ‘standard’ set of 
about two dozen address fields and cal¬ 
culations, including City, State and M 
ZipText fields. The ZipText field con¬ 
tains both five-digit and nine-digit ZIP 
codes. The ZIP Table file has just three 
fields: City, State and ZipText. ZIP Table 
contains all 43,000 + five-digit ZIP codes 
for the U.S. and each associated City and 
State. The goal is to set up the Master Ad¬ 
dress file so that it will look up the City 
and State field information from the ZIP 
Table file whenever a ZIP is entered or 
edited in the Master Address file. 

Why would we bother? (a) We get cor¬ 
rect, consistent entry of City and State in¬ 
formation if the ZIP is correct; (b) We save 
perhaps a dozen keystrokes for each ad¬ 
dress entered. Both (a) and (b) save us 
time and money - lots of time and money 
if we are entering lots of addresses. 

Step 1. In the Master Address file make 
sure that the ZipText field is a text-type. 
(Always, always store ZIPs as text. If you 
need a numeric version of the ZIP code for 
sorting or some other purpose, calculate it 
from ZipText.) 

Step 2. Create a new field called Zip- 
TextFive that extracts five-digit ZIP codes 
from the ZipText field. ZIP Table contains 
only five-digit ZIPs and will not provide a 
lookup match for nine-digit ZIPs. 

Step 3. In the Master Address file, 
define the lookup for the City field. Choose 
Field Definitions... from the Select menu. 
Click once on the City field. Click the Op¬ 
tions button. Make sure there is an X in 


Master Address 


ZIP Table 


Important 


In the no-match look¬ 
up options, "copy 
next lower value" and 
"copy next higher 
value" refer to source 
key values in the look¬ 
up file, not data 
values. This distinc¬ 
tion is not clear in the 
lookup definition 
dialog. 


ZipTextFive = 
Left (ZipText,5) 
{text result} 


the lookup option check box and click on 
the Set Lookup... button if FileMaker has 
not already done so for you. 

If this is a new lookup definition, you 
will be asked to specify the file that will 
serve as the lookup file.( If the City field 
had already been defined as a lookup, click 
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Figure 10 


the Set Lookup File... button to specify the 
lookup file.) Select ZIP Table to be the 
lookup file. 

You are now ready to specify the two 
key fields and the source data field. Figure 
10 is a composite showing the three pop- 
ups to be used. FileMaker already knows 
the destination data field - it is the one you 
selected in the field definition dialog on 
your way to this point. And FileMaker al¬ 
ready knows the name of the lookup file. 

The source data field popup shows a list 
of the fields available in the lookup file. In 
this case we want to pick the City field: 
hold the mouse pointer down, drag to 
highlight City and then release the mouse. 


Similarly, the source key field 
is specified with another pop¬ 
up. The source key for the 
task at hand is ZIPText. 

Tlje destination key field 
selection is similar. Just scroll 
and select the key field, in this 
case, the calculated ZipText- 
Five field. 

Step 4. Select what you 
want to occur if a lookup 
should fail. Select one of the 
buttons in the sub-box in the 
lower left corner. In this par¬ 
ticular case, do not use the 
next-smaller or next-larger 
options - after all, you don’t 
want to pull in some other City if the ZIP is 
entered incorrectly. Either specify that no 
lookup occurs, or enter a message to be 
used. I use ‘Error’ to help check that I have 
the ZIP entered correctly. 

When you’ve entered all the needed in¬ 
formation, your finished lookup definition 
dialog should look very much like the one 
in Figure 11. 

Step 5. Exit the lookup definition and 
the subsequent Options dialogs to arrive 
back at the field definition box. Repeat 
steps 3 and 4 for the State field. Exit every¬ 
thing and get back to Browse mode. 

Step 6. Make several tests of the new 
lookup by entering some good ZIP codes 


Minor Problem 

If you ever need to recreate a lookup file from scratch, be sure to enter the field names in the same order 
as they were in the original file. When we recently updated our ZIP lookup table, I made a new one rather 
than clone the old one - there were only three fields to define. I then imported the new ZIP data into the 
newly created file and substituted it for our old ZIP table. The next day, the address files that depend on the 
ZIP table were not looking up the City correctly. When I examined the lookup definition, I noticed that City 
was no longer defined as the source data field. It turns out that I reversed the order that I entered the City and 
State fields and FileMaker evidently uses the as-entered field order rather than the field name for the lookup. 
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and checking the City and 
State fields for proper lookup. 
You should also enter a few 
known-bad ZIP codes to see 
what happens. 96165 and 
95933 and 92616 should not 
provide proper lookups. 

92607 with the zero entered as 
the capital letter O should pro¬ 
vide a wrong answer. 

Step 7. Enjoy the benefits 
of FileMaker lookups! 


Figure 11 
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Correspondence File Followup By Mike Harris 

In issue #411 had the temerity to suggest using File¬ 
Maker as a word processor for short correspondence. Soon 
thereafter Joe Kroeger and I had occasion to appear at a 
FileMaker seminar. A number of professional FileMaker 
consultants were there and they all used FileMaker for let¬ 
ters! Indeed, most had been doing so for years. It seems 
that the article wasn’t as off-beat as I had feared. Don’t feel 
chagrined if word processing in FileMaker works for you. 

I got a particularly interesting letter from a subscriber 
in Vancouver, Canada. He has carried the logic of data- 
base-driven correspondence to its ultimate conclusion. He 
is in the travel business and exhibits at trade shows. To get 
personalized follow-up letters to the potential customers 
he sees at shows, he produces custom letters based on 
questions he asks at the show. The text of the letter is deter¬ 
mined by answers from the questionairess. In his words: 

“I am constandy inundated with unoriginal mass mail¬ 
ings that I find boring and dull. I knew there were more 
people like me out there so I wanted to ensure that my 
mailing at least didn’t appear to be mass produced (al¬ 
though it was). The letter addressed all questions answered 
by the prospect. The result was 500 completely custom let¬ 
ters. Since the questions and letter text were prepared be¬ 
fore the trade show the data entry was completed in a few 
hours the day after the show. My letters were printed, 
signed and delivered to everyone before the end of the 


week.. .more than a few new customers were impressed.” 

I have done quite a few trade shows myself and I know 
how impossible it is to remember conversations with more 
than a few prospects. The result is that a lot of the effort is 
lost because there is no adequate followup. I see no reason 
why custom letters could not be generated for everyone 
you talk to at a trade show, if a scheme for noting key as¬ 
pects of conversations were developed. If this turned out to 
be too crude, the rough letter text could certainly be gener¬ 
ated and then edited individually. 

Our reader goes on to talk about using this technique 
for Fax letters: “I’ve had tremendous response by sending 
out letters to my travel agent clients using a FAX layout I 
created in FileMaker Pro_[I’d like the FAX unit to] rec¬ 

ognize the FAX number field and dial the number. Think 
about this for a minute, if you have a lot of bills to send 
out,... [why not] send out a group of custom FAXes?” 

When Claris adds IAC hooks to FileMaker, it should be 
possible to do this FAX dialing easily with programs like 
Frontier. Personally, I think the whole area of customizing 
letters, catalogs and other bumpf from database informa¬ 
tion is very interesting. I intend to try the trade show fol¬ 
low-up letter idea at the next MacWorld Expo in San Fran¬ 
cisco. The FileMaker Report and my consulting company, 
Watertechnics, will both have booths in the FileMaker Pro 
Resource Center, room 212 in Moscone Center, January 
13-15. Come visit us and we’ll talk FileMaker stuff! 
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Equation du Jour: Calculating Date Quarters 


By Joe Kroeger 

FileMaker pro includes a nice set of 
date-related functions that can be used in 
equations. But no Quarter. We can extract 
any of three date components from a 
whole date: the year, the month and the 
day. We can assemble a set of three num¬ 
bers and convert them to a date. “Today” is 
available for calculations and for auto-en¬ 
try into fields. Even the names of days and 
months can be calculated. The day of the 
year and the week of the year can be de¬ 
rived from a date. There are also functions 
for converting a date into text and text into 


mean by a ‘quarter’. (Perhaps Claris did 
not include a Quarter function because 
there are too many different types!) You 
might define calendar quarters by groups 
of three-month intervals or, alternatively, 
by 13-week intervals. Some people distin¬ 
guish between calendar and fiscal quarters. 
Some people start quarters on the first date 
of the first month or week of the quarter 
and some on the first Monday. Some peo¬ 
ple start the first quarter of the calendar 
year on January first and some on the start 
of the nearest 13-week interval or nearest 
Monday, no matter where that may fall. If 
you use the Pro WeekOfYear function, be 
clear about when it counts the first week. 


Date Format for “NemRecordDate” 


O Leaue date formatted as entered 
® Format as: 


4th Quarter, 1991 


] 


Separator character for numeric dates: 


/ 


] 


□ Shorn day and month numbers with leading zeroes 
Sample -. 


4th Quarter, 1 991 


(Tent Format... ] 


Cancel 


]QO 


Calculate Calendar Quarters 
But let’s assume that you want to 
define quarters as three-month intervals 
that start on January 1 every year. Your 
task is to allow an invoice file to report 
on results by quarters. An equation for 
allocating an InvDate into one of four 
quarters takes advantage of the Month 
function and looks like this: 


Figure 1 


a date. All very useful and powerful stuff 
for solving many types of date problems. 

But Pro does not include a function that 
calculates calendar quarters. Date fields can 
be formatted to show quarters; Figure 1 
shows the date formatting dialog. For some 
kinds of reports formatting by quarters is 
sufficient. But if you need to calculate a 
calendar Quarter you must derive it for 
yourself. Fortunately, it is not a problem. 

What is a Quarter? 

The first step is to define what you 


InvQuarter = {numeric result} 

If (Month(lnvDate) = 1 
or Month(lnvDate) = 2 
or Month(lnvDate) = 3, 1, 

If (Month(lnvDate) = 4 
or Month(lnvDate) = 5 
or Month(lnvDate) = 6, 2, 

If (Month(lnvDate) = 7 
or Month(lnvDate) = 8 
or Month(lnvDate) = 9, 3, 4))) 

Translated into words this equation 
says: “If the month of the InvDate is 1 or 2 
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or 3, the InvQuarter is 1; if the month of 
the InvDate is 4 or 5 or 6, the InvQuarter is 
2; if the month of the InvDate is 7 or 8 or 
9, the InvQuarter is 3; otherwise the Inv¬ 
Quarter is 4.” 

Note that it is not necessary to extend 
the conditional test into months 10, 11, 
and 12. Since those are (presumably) the 
only remaining alternatives, InvQuarter = 

4 should end up as the result when the 
month is not 1 through 9. 

The equation result can be text or nu¬ 
meric - a numeric result would be pre¬ 
ferred if you wanted to use the value in a 
subsequent calculation for some reason. 
Once the number of the quarter is known, 
you can put the InvQuarter field on the 
layout next to layout text that says some¬ 
thing like “Q” or “Quarter”. 

Variations 

Another version of this equation can be 
used to generate alternative results for the 
name of the quarter and to save having to 
work with layout text: 

InvQuarter = 

If (Month(lnvDate) = 1 
or Month(lnvDate) = 2 
or Month(lnvDate) = 3, 

If (Month( InvDate) = 4 
or Month(lnvDate) = 5 
or Month(lnvDate) = 6, 

If (Month(lnvDate) = 7 
or Month(lnvDate) = 8 
or Month(lnvDate) = 9, 

"Quarter 4"))) 

(Of course you can use “Ql” or “Qtr 1” 
instead of “Quarter 1” if desired.) 

Another version can be a little shorter 
by using < instead of three ‘or’ statements: 


{text result} 

"Quarter 1", 

"Quarter 2", 

"Quarter 3", 


InvQuarter = {text result} 

If (Month(lnvDate) < 3, "Quarter 1", 

If (Month(lnvDate) < 6, "Quarter 2", 

If (Month(lnvDate) < 9, "Quarter 3", 
"Quarter 4"))) 

If you define quarters as 13-week inter¬ 
vals you can construct a different equation. 

InvQuarter = {text result} 

If (WeekOfYear(lnvDate) < 14, "Ql", 

If (WeekOfYear(lnvDate) < 27, “Q2", 

If (WeekOfYear(lnvDate) < 40, "Q3", 
"Q4"))) 

It is possible to write a more complicat¬ 
ed version of this last equation by specify¬ 
ing the exact week range for each quarter. 

It would look like this: 


FileMaker Pro 
Date Functions 


Today 

Month 

Day 

Year 

Date 

DayOfYear 

WeekOfYear 

DayName 

MonthName 

TextToDate 

DateToText 


InvQuarter = {text result} 

If (WeekOfYear(lnvDate) < 14, "Ql", 

If (WeekOfYear(lnvDate) >13 and 
WeekOfYear(lnvDate) < 27, "Q2", 

If (WeekOfYear(lnvDate) > 26 and 
WeekOfYear(lnvDate) < 40, "Q3", 

"Q4"))) 

But this approach is not necessary as 
long as you write the If tests in the second 
equation in this column in the sequence 
shown. In that equation, when the “< 14” 
test is positive, Ql is the result and the rest 
of the equation is skipped by FileMaker. 
When the “< 14” test is negative, the “< 

27” test is invoked. Since you won’t get to 
the “< 27 test” unless “< 14” fails, it is logi¬ 
cally not necessary to expand to 
“WeekOfYear(InvDate) > 13 and 
WeekOfYear(InvDate) < 27” although that 
design will also work. 

Once the appropriate quarter has been 
derived, it is a straightforward task to Sort 
on the Quarter and make sub-summary 
reports that provide quarterly results. 

♦V* - 
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Speeding Import/Export in FileMaker Pro 


Author's Note 


I find the new Pro 
export/import field 
list dialogs to be a 
welcome feature and 
a generous enhance¬ 
ment to database 
technology. I LOVE 
the import dialog 
showing the incoming 
data and which field it 
will go into. Thank 
you Claris! 


Editor's Note 


Second the motion! 
Thank you Claris! 


Figure 1 


By S.C. Kim Hunter 
Acropolis Software 

FileMaker pro can appear to be tak¬ 
ing much longer to export data compared 
with FileMaker II. A main reason is a 
change in the way calculations are treated 
on export and import. The purpose of this 
article is show how export and import can 
be controlled to reduce time and file size. 

How FileMaker II Exports & Imports 

A common way to back up a FileMaker 
database is to export all the data to a text 
file, then save a clone of the file. This pre¬ 
serves all the information and layouts in 
the smallest possible disk storage space. 
During export to a text file FileMaker II 
provided an Exclude button to omit calcu¬ 
lation results from export. If the export was 
for the purpose of saving data for backup, 
there was no need to export calculation re¬ 
sults because those values couldn’t be im¬ 
ported back into the file. Only when data 
was being transfered to another application 
or computer might it be necessary to ex¬ 
port calculations. 


Specify field order for euport 


y 

Unit Cost 

L> 

y 

Amount 


y 

Subtotal 


y 

Tax SB 


y 

Tax Amount 


y 

Invoice Total 



OriHid Tel 


y 

Item Number 


y 

Paid 


y 

Shipped 

-rr 

y 

Due 


y 

Printed 


y 

Vendor Master 


y 

Phone 

iiii 

y 

Date Paid 

o 


® Don't format output 
O Format output using current layout 


[ Cancel ] [[ OK ]| 


There is a definite problem with this 
arrangement: if the effect of exporting cal¬ 
culation results wasn’t understood and the 
Exclude button wasn’t clicked when ex¬ 
porting backup data, re-importing was 
very likely to scramble data by loading cal¬ 
culation results into other fields. There is 
no simple way to recover from this. I’m 
sure that was a source of confusion and 
great agony for those attempting to restore 
their only backup. 

How FileMaker Pro Exports & Imports 

FileMaker Pro, as the default, exports 
all calculation values, then, on reimport 
skips over that calculated data as the text 
file is read. In general this approach is good 
because it reduces the chance of scrambling 
data by eliminating the Exclude decision. 
However, a large amount of calculated 
field data increases the export and re¬ 
import times and also increases file sizes. 
Unfortunately there is also a problem with 
summary fields getting in the way of reim¬ 
ported data and causing data scramble as 
discussed below. 

It is possible in Pro to turn off export of 
calculations although the process is a bit 
more complex than clicking one Ex¬ 
clude button. When Export is chosen 
from the File menu and after a name is 
entered for the text file, the ‘export field 
order’ dialog appears with a list of fields 
as shown in Figure 1. In this list, sum¬ 
mary fields are automatically dimmed 
(Grand Total in Figure 1) and can’t be 
exported. To the left of the list is a nar¬ 
row column of check marks. Moving the 
mouse into this column turns the cursor 
into a check mark. Clicking checks an 
unchecked row (if not dimmed) or, if 
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checked, removes the check. The checked Import Problem with Summary Fields 
fields are the ones that are exported. For There is one fly in the ointment. Sum- 

unchecked fields, no data is exported nor is mary fields can get in the way and can foul 
any “place” saved for that field in the ex- up reimporting data by misaligning the im¬ 
ported text (as might be done by inserting port data and fields. As shown in Figure 2, 

a tab with no data). Fields can be re- the import value “CC-735” was exported 

arranged in the list by dragging a field from the Item Number field but is shown 

name up or down. lined up with Grand Total. The value “y” 

The export list dialog doesn’t show the lines up with Item Number but is from the 

type of each field so you can’t tell which Paid field. So all the data at and below the 

are calculations. All fields except summa- Grand Total summary field are offset by 

ries are automatically checked when the one and will import into the wrong field, 
export dialog opens, so calculation results There are two ways to resolve this prob- 

will be exported along with other data. lem. The best way is to revise the field defi- 

This is the reason for increased export nitions so that all summary fields are de¬ 
times relative to a FileMaker II version of fined last. The natural way of creating a 

the same database. More calculation fields database is to add the summaries last and, 

with longer results, especially text results, if that is the case in your file, summary 

increase the export time and text file size. fields will cause no problems with export/ 

If exporting calculation results was a import. But summary fields can get stuck 
bad thing to do in FileMaker II, why isn’t up inside the field definition list when new 
that true in Pro? Because Pro automatically fields are added. 

accounts for calculations and prevents im- It is possible to open the Field Defini- 

port of calculated data in the import pro- tion dialog and move fields up or down in 

cess. Figure 2 shows an import field order the field definition list by dragging them. 

dialog for the same fields as Figure 1. On There is also a pop-up menu with four se- 

the right, several field names are dimmed - lections to change the order of the field def- 

one of those (Grand Total) is a summary inition list. However, this will not affect the 

field, but the calculation fields are Figure 2 


also dimmed. On the left is a data 
image of one of the records about 
to be imported. Data which lines up 
with a calculation field (dimmed) 
although present in the text file, will 
be skipped over when the data is 
imported, as indicated by a dotted 

line (.) in the middle column of 

Figure 2. So it is possible to export 
all the data and reimport it without 
clicking anything in the export and 
import dialogs; the decision needed 
in FileMaker II about the Exclude 
button has been eliminated. 
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Wish List 


Perhaps a future 
version of FileMaker 
will have an option so 
that names can be 
dragged with either 
the current 'exchange' 
method or by a 'Cut & 
Paste' method which 
would shift all names 
between the start and 
end position of the 
moved field (and a 
good description in 
the manual as to 
when each method 
should be used). 


Figure 3 


order in which fields appear in the import 
or export dialogs. The default import order 
can be changed only by deleting a summa¬ 
ry field in the field definition dialog then 
redefining it. This also requires replacing it 
on any layouts. 

My method to move definitions is to 
(1) print the field definitions so I know 
what the summary fields summarize; (2) 
from the File menu, choose Access Privi¬ 
leges. .. Overview. .. to find which layouts 
the summary fields are on; (3) define new 
summary fields with almost the same 
names; (4) go through all layouts and for¬ 
mat and place the new summaries right 
over the top of the old ones and edit any 
labels to the new names (so they won’t be 
deleted later); (5) go back to the field defi¬ 
nition dialog and delete the old summary 
fields (which automatically takes them off 
all the layouts). (The new summary names 
can then be changed to match the original 
ones if desired.) This method reorders the 
field definition list permanently so there 
will never be a problem with summaries 
misaligning the import data. This can get 
complicated if summaries are used in sum¬ 
mary calculations so take care. 


The second way to move summary 
fields out of the way in the import field or¬ 
der list is to drag the other (non-summary) 
fields up one at a time until they each line 
up with their appropriate data. After all the 
data fields are moved up, the summary 
fields are at the bottom of the import field 
order list. You might be tempted to drag 
the summary field down all the way to the 
bottom in one step but that doesn’t work 
because of the way Pro rearranges names 
after one is moved. Rather than moving 
the whole list one row, the name being 
dragged is exchanged with the name in the 
place where the moved name has been 
dragged. Figure 3 shows what happens 
when Grand Total summary is dragged 
down two rows in one step. Paid moves up 
into the place where Grand Total was and 
Item Number stays put. Rats. 

You might expect that both Item Num¬ 
ber and Paid would move up one row. If 
that were the case. Grand Total could be 
dragged all the way to the bottom and all 
the fields below the empty position would 
move up one row. Not so. If the dragging 
process worked that way, it would be far 
easier to misalign import data, so Claris 

decided on the exchange method as 



best. As I hope you see, you are 
much better off to alter the field 
definitions so all summary fields 
are at the bottom of the definition 
list (or better yet, design the file 
that way in the first place). 

Another comment on moving 
fields in the import dialog: Think of 
the dragging process in terms mov¬ 
ing a name to the place where it be¬ 
longs (matches the appropriate in¬ 
coming data) rather than moving 
another name out of a place where 
it doesn’t belong (doesn’t match 
the data). There is a subtle differ- 
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ence but thinking in the first way will get 
you more in tune with the way Claris de¬ 
signed the list to work. 

Back to the Backup 

Now that we have the summary fields 
out of the way, we can go back to talking 
about calculations, recalling that our objec¬ 
tive is to avoid export of calculation results 
to save time and file size. If export is being 
done when no calculation results are need¬ 
ed, such as in saving the data for backup, 
the calculation fields can be excluded by 
unchecking their names in the export dia¬ 
log (Figure 1). However, it isn’t an easy job 
because you don’t know which fields are 
calculations. A list of the fields can be 
printed (in the Print dialog click the Field 
Definitions button at the bottom.) Note 
that the field definition dialog has a pop¬ 
up with four choices to reorder the field 
definition list. That order is used for print¬ 
ing the field definitions. Choosing View by 
field type will print the field definitions 
with all the calculations grouped together 
making it easier to use the printed list to 
spot calculations in the import order list. 

Armed with the printed field defini¬ 
tions, the export dialog can be opened and 
calculation fields clicked off - calculated 
results are then excluded from the export. 

While this technique saves export time 
and file size, there is an annoying side ef¬ 
fect which occurs when reimporting the 
data. The incoming data will be aligned 
with each field in the import field list dia¬ 
log. Since no calculation fields were ex¬ 
ported, field values can be aligned with cal¬ 
culation fields, and if left that way for 
import, that data will be thrown away. 

What is necessary is to click on the 
non-calculation field names in the import 
field list and drag those names up to the 
point where they match the appropriate 


data. As this is done, the calculation field 
name will move down into the place of the 
name being dragged up. Eventually all the 
calculation fields will locate at the bottom 
of the list below all the data fields. Now the 
import data should line up with the appro¬ 
priate data fields. As mentioned for the 
summary fields, this step can be avoided if 
all the calculations are defined last in the 
field definition list. However, deleting and 
redefining calculation fields is much more 
difficult and risky so I suggest dragging up 
other fields in the import order list. 

Once you have finished dragging fields 
around and are certain the fields are in the 
correct order, I recommend creating a 
script to capture the import order list. The 
same can be done for the export order. 
That way you won’t have to re-create the 
field sequences. 

Summary 

If all calculations and summary fields 
are defined last in the field definition list, 
data can be exported and reimported with¬ 
out paying any attention to the field order 
lists in the export and import dialogs. 
However, since calculations will be export¬ 
ed and skipped on reimport, export and 
import time will be longer and the text file 
size will be larger. 

Export/import time and text file size 
can be reduced by eliminating calculation 
results from both the export and import 
field order list by unchecking the names of 
the calculation fields. 

If all calculations followed by all sum¬ 
maries are not located at the bottom of the 
field definitions, field names for text, num¬ 
ber and date fields have to be dragged up 
in the import field order list to the place 
where they match the incoming data values. 

Define scripts to preserve those export/ 
import orders for future use. 


Suggestion 


One possible aid for 
this rearranging pro¬ 
cess is to adapt a field 
naming convention 
that makes it easy to 
identify summary and 
calculation fields. 
"CalcZipLength", for 
example, or 
"SummMonthTotal". 
You get the idea. 
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